(12) INTERNATIONAL APMfCATlON PUBLISHED UNDER THE PATENT COOWrATION TREATY (PCT) 



(19) World Intellectual Property Organization 

International Bureau 




44HHMH1IIIE1 lllll I II III Dill Hill llllllllll IM lllllfl IIII IIII Dll 



(43) International Publication Date (10) International Publication Number 

20 September 2001 (20.09.2001) PCT WO 01/69869 A2 



(51) International Patent Classification 7 : H04L 12/56, 

29/06 

(21) International Application Number: PCT/IB0 1/00352 

(22) International Filing Date: 13 March 2001 (13.03.2001) 

(25) Filing Language: English 

(26) Publication Language: English 



(30) Priority Data: 

09/527,786 



17 March 2000 (17.03.2000) US 



(71) Applicant: NOKIA CORPORATION [FI/FI]; Keilalah- 
dentie 4, FTN-02150 Espoo (FT). 

(71) Applicant (for LC only): NOKIA INC. [US/US]; 6000 
Connection Drive, Irving, TX 75039 (US). 

(72) Inventors: VAN VALKENBURG, Sander; Kalevankatu 
44 A12, FLN-00180 Helsinki (FT). PALOMAR, Marc, Sol- 
sona; Teljantie 9 A 3, FIN-00350 Helsinki (FI). 



(81) Designated States (national): AE, AG, AL, AM, AT, AU, 
AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CR, CU, CZ, 
DE, DK, DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, 
HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, 
LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, 
NO, NZ, PL, FT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, 
TR, TT, TZ, UA, UG, UZ, VN, YU, ZA, ZW. 

(84) Designated States (regional): ARIPO patent (GH, GM, 
KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian 
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European 
patent (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, 
IT, LU, MC, NL, FT, SE, TR), OAPI patent (BF, BJ, CF, 
CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG). 

Published: 

— without international search report and to be republished 
upon receipt of that report 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations'* appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



(74) Agents: KELLY, Robert, H. et al.; Novakov Davis & 
Munck, PC, 900 Three Galleria Tower, 13155 Noel Road, 
Dallas, TX 75240 (US). 



(54) Title: APPARATUS, AND ASSOCIATED METHOD, FOR ROUTING PACKET DATA IN AN AD HOC WIRELESS COM- 
MUNICATION SYSTEM 



3 



< 

oo 
as 



12, ' SLAVE 4 

7^ is-K) 

SLAVE 2 / "X \ 



/ 18-2~ 
/ SLAVE 3/MASTER A 

» 18-1 ..-'-'"^16/18-3 

NOT \ — 



SLAVE 5 
^18-5 



.A 



MASTER B" 



Si 







(57) Abstract: Apparatus, and an associated method, by which to route packets of data between a data source node (18-1) and a 
data destination node (18-6) in an ad hoc, wireless network, such as a Bluetooth scatternet (10). Data routing tables (26, 28, 32) are 
provided to each node, and header information extracted from a packet header (36) is used by such tables (26, 28, 32). Routing of a 
packet of data is effectuated in a hop-by-hop manner to effectuate the communication of the packet from the data source node (18-1) 
to the data destination node (18-6). 
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APPARATUS, AND ASSOCIATED METHOD, FOR ROUTING PACKET 
DATA IN AN AD HOC WIRELESS COMMUNICATION SYSTEM 

5 The present invention relates generally to a 

manner by which to communicate packet data in an ad 
hoc, wireless communication system, such as a 
Bluetooth scatternet. More particularly, the present 
invention relates to apparatus, and an associated 

10 method, by which to facilitate routing of packet- 
formatted data pursuant to a communication session in 
the Bluetooth scatternet, or other ad hoc, wireless 
communication system. A new packet header is provided 
to facilitate routing of the packet - formatted data so- 

15 formed. And, new tables are provided for each node in 
a communication path utilized during a communication 
session to facilitate the routing of the packet data 
pursuant to a hop-by-hop communication scheme. 

BACKGROUND OF THE INVENTION 
20 Technological advancements in communication 

technologies have permitted the introduction, and 
popularization of usage, of new types of communication 
systems . Communication devices of both increased 
processing capacities and of smaller sizes are able to 
25 be utilized in applications and in situations not 
previously possible or practical . 

New wireless communication systems, and 
communication devices operable therein, have been made 
possible as a result of such advancements. A cellular 
30 communication system capable of communicating packet 
data is exemplary of a new wireless communication 
system made possible as a result of technological 
advancements. A Cellular communication system 
includes a network infrastructure which is installed 
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in a geographical area and affixed in position. 
Mobile terminals operable in a cellular communication 
system communicate by way of the network 
infrastructure . 
5 Additional types of communication systems have 

been proposed which also take advantage of the 
advancements in communication technologies. For 
instance, ad hoc, i.e., infrastructure-free, 
communication systems have been proposed. The 

10 Bluetooth standard sets forth an ad hoc, communication 
system which provides for wireless connectivity of a 
large number of different devices. Bluetooth devices 
are connectable in an ad hoc manner by way of short - 
distance radio links, thereby to permit data to be 

15 communicated between such Bluetooth devices. Each 

Bluetooth device forms a node in the Bluetooth system, 
sometimes referred to as a Bluetooth scatternet . But, 
because a Bluetooth system, unlike a cellular 
communication system, does not have a fixed 

20 infrastructure, effectuating communications 
therethrough is made more difficult. 

The Bluetooth devices are potentially mobile, and 
movement of the Bluetooth devices necessitates 
corresponding link changes as a result of such 

25 movement. The Bluetooth standard defines piconets 

formed of a master and slave relationship between one 
Bluetooth device forming a master and up to seven 
Bluetooth devices forming slaves to the master. A 
master of one piconet might also be a slave in another 

30 piconet, and the piconets together define a 

scatternet. Communicatons are effectuable between 
Bluetooth devices positioned within different 
piconets. Random access by a Bluetooth device to 
communicate in the Bluetooth scatternet is not 



WO 01/69869 




PCT/IB01/00352 



permitted as the master Bluetooth device of each 
piconet controls the access to the system. Instead, 
to form a connection by which to effectuate a 
communication session, the Bluetooth devices must 
5 register with each other in order to set up a 

connection in which of the devices, i.e., the master, 
controls the connection. 

Existing routing protocols by which to 
communicate packet data do not adequately take into 

10 account the unique aspects of an ad hoc network. 

Routing protocols developed for fixed networks are not 
suitable as such protocols are not able to adapt to 
link changes which occur in a Bluetooth scatternet, or 
other ad hoc, network. And, while other routing 

15 protocols have been developed for general ad hoc 

networks, the unique features and limitations of a 
system implemented pursuant to the Bluetooth standard 
limit the usefulness of such existing routing 
protocols to effectuate communications in a Bluetooth 

20 scatternet. A routing protocol for a Bluetooth 
scatternet must exhibit an appropriate trade-off 
between relieving nodes in a communication path formed 
pursuant to a communication session of processing, 
routing, and other overhead, information while also 

25 keeping track of the routes forming communication 
paths even in lieu in changing network topologies. 

If a manner could be provided by which better to 
route packet data in an ad hoc, wireless network, such 
as a Bluetooth scatternet, improved communications 

30 therein would be possible. 

It is in light of this background information 
related to ad hoc, wireless networks that the 
significant improvements of the present invention have 
evolved . 
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SUMMARY OF THE INVENTION 
The present invention, accordingly, 
advantageously provides apparatus, and an associated 
method, by which to facilitate routing of packet- 
5 formatted data and in an ad hoc, wireless 

communication system. Through operation of an 
embodiment of the present invention, routing of packet 
data between any pair of nodes within a Bluetooth 
scatternet is made possible. 

10 The routing protocol provided pursuant to an 

embodiment of the present invention is compatible with 
existing IPv4 and IPv6 protocols. Additionally, 
higher- layer protocols, such as TCP (Transport Control 
Protocol) or UDP, are overlayable upon the routing 

15 protocol, thereby to be transparent to users. 

In one aspect of the present invention, a new 
packet header structure is provided. The packet 
header structure is shorter, relative to conventional 
IP headers. In one implementation, the packet header 

20 structure, herein referred to as a PicoIPv4 packet 

structure, replaces existing IPv4 packet headers. In 
another implementation, a new packet header structure, 
referred to herein by PicoIPv6, replaces conventional 
IPv6 packet headers. The type of header structure 

25 utilized, for instance, is dependent upon the version 
of IP expected by a Higher layer of protocol, such as 
the TCP or UDP layer. 

In another aspect of the present invention, new 
tables are defined for each Bluetooth device which 

30 forms a node in a communication path, inclusive of a 
Bluetooth data source node and a Bluetooth data 
destination node. Each Bluetooth, or other ad hoc, 
device is capable of forming a master device or a 
slave device, and each of the Bluetooth devices 
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includes a mapping table for mapping incoming packets 
to outgoing packets received at, and forwarded on, by 
a communication node. Also, each of the devices 
includes an IP routing table for mapping IP addresses 

5 to a subsequent hop address defining a subsequent node 
in the communication path. And, each of the Bluetooth 
devices also includes a table that maps a currently- 
allocated local identifier and the device's associated 
master's identifier. Information utilized to fill the 

0 tables is obtained from packet header information 
contained in the packet header structure of packet 
data applied to each node in the communication path. 
By storing the information in the tables provided to 
each of the nodes, routing information thereby becomes 

5 stored at the tables of the nodes in the communication 
path. 

In another aspect of the present invention, 
datagram communication is provided to communicate 
packet data between a data source node and a data 

0 destination node within a piconet, within the 
Bluetooth scatternet, or between a node of the 
scatternet and a node of a fixed network, e.g., the 
Internet, to which a Bluetooth device is coupled. 
Hop-by-hop routing of the packet data is utilized in 

5 which every node involved in the communication path 

from the data source node to the data destination node 
determines, based upon information stored at the 
tables of the respective nodes, to which next hop, 
i.e., node, the packet data is to be transported. 

0 Hop-by-hop routing is permitted as the routing 
information about all ongoing connections in a 
communication path in the scatternet are contained in 
routing tables maintained by each node involved in the 
communication session or connection. Each packet is 
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sent from hop to hop, i.e., from node to subsequent 
node, and must therefore contain an identifier for the 
subsequent hop and also the final destination, i.e., 
the data destination node. For the destination node, 
the IP address thereof suffices, for the data source 
node, the local identifier thereof is utilized. Each 
packet is further identified to indicate the 
connection, that is, communication session. A 
sequence number is utilized to identify packets. Each 
node that communicates a packet to a subsequent hop, 
i.e., node, identifies a packet belonging to a certain 
connection with a certain destination with a unique 
sequence number. The sequence number is assigned when 
setting up the connection. 

Due to the inherent mobility of at least some 
Bluetooth devices, their movement affects the routing 
tables contained at each of the devices. When a 
Bluetooth device moves, the location thereof within 
the Bluetooth scatternet changes, or, the Bluetooth 
device moves out of communication range of the 
scatternet. The tables provided to the Bluetooth 
devices pursuant to an embodiment of the present 
invention contain information in such tables to 
facilitate appropriate route setup, and rerouting, to 
take into account the movement of such Bluetooth 
devices . 

In these and other aspects, therefore, apparatus, 
and an associated method, is provided for facilitating 
routing of packets of data between a data source node 
and a data destination node by way of a communication 
path formed in a multinode, ad hoc, wireless 
communication system. The communication path has at 
least one node, inclusive of the data destination 
node. The apparatus comprises at least one first 
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routing table having an incoming data ledger and an 
outgoing data ledger in which the first routing table 
maps an incoming data packet into an outgoing data 
packet . 

5 A more complete appreciation of the present 

invention and the scope thereof can be obtained from 
the accompanying drawings which are briefly summarized 
below, the following detailed description of the 
presently-preferred embodiments of the present 
10 invention, and the appended claims. 

BRIEF DESCRIPTION OF THE DRAWING 
Figure 1 illustrates a functional representation 
of an exemplary Bluetooth scatternet, exemplary of an 
ad hoc, wireless network in which an embodiment of the 
15 present invention is operable. 

Figure 2 illustrates a functional representation, 
similar to that shown in Figure 1, of a Bluetooth 
scatternet; also exemplary of an ad hoc network in 
which an embodiment of the present invention is 
20 operable . 

Figure 3 illustrates a representation of the 
format of a packet header structure provided pursuant 
to an embodiment of the present invention of a packet 
of data. 

25 Figure 4 illustrates a representation of a 

routing table positioned at each Bluetooth device of 
the scatternets shown in Figures 1 and 2 pursuant to 
an embodiment of the present invention. 

Figure 5 illustrates a representation of another 
30 routing table, also provided to each Bluetooth device 
of the scatternets shown in Figures 1 and 2. 

Figure 6 illustrates a representation of an 
address mapping table also provided to each Bluetooth 
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device of the Bluetooth scatternets shown in Figures 1 
and 2 pursuant to an embodiment of the present 
invention. 

Figure 7 illustrates a communication path formed 
in a Bluetooth scatternet and pursuant to which an 
embodiment of the present invention is operable. 

Figure 8 illustrates a communication path formed 
in a Bluetooth scatternet, here further coupled to a 
fixed packet data network, and pursuant to which an 
embodiment of the present invention is operable. 

Figure 9 illustrates a representation of an agent 
routing table, also utilized pursuant to an embodiment 
of the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
Referring first to Figure 1, a representative 
portion of an exemplary Bluetooth scatternet, shown 
generally at 10, provides for packet communications 
between Bluetooth devices operable therein. While the 
following description of the present invention shall 
be described with respect to a Bluetooth system, such 
a system is representative of an ad hoc, wireless 
communication network. In other implementations, 
various embodiments of the present invention are 
operable therein. And, operation of various 
embodiments of the present invention can similarly be 
described with respect to such other ad hoc, wireless 
communication networks . 

The Bluetooth scatternet 10 shown in Figure 1 
includes two piconets, a first piconet 12 and a second 
piconet 14 . Each piconet of the scatternet is defined 
by a master Bluetooth device and up to seven slave 
Bluetooth devices. Here, the first piconet 12 is 
defined by a master Bluetooth device 16 and four slave 
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Bluetooth devices 18, here referenced by 18-1, 18-2, 
18-3, and 18-4. And, the second piconet 14 is defined 
by a master Bluetooth device 22 and two slave devices 
18, here referenced by 18-4 and 18-5. 
5 Figure 2 also illustrates a representative 

portion of the Bluetooth scatternet 10. Again, the 
portion illustrated includes the first piconet 12 and 
the second piconet 14 wherein the first piconet is 
defined by a master device 16 and four slave devices 

10 18-1, 18-2, 18-3, and 18-4. Here, though, the second 
piconet 14 is defined by a master device which is a 
slave device to the master device 16 of the first 
piconet . The device forming both a slave and a master 
is referenced by 18-4/22. 

15 The devices which form the Bluetooth scatternet 

are mobile and form, on an ad hoc basis, the network 
of the Bluetooth scatternet. Through movement of the 
devices which form the scatternet, the various 
piconets of the scatternet are redefinable, as 

20 appropriate, and the Bluetooth devices of the 

scatternet are variously slave devices and master 
devices, sometimes, and as indicated by the device 18- 
4/22, shown in Figure 2, form both a slave and a 
master device in separate piconets. Because of the ad 

25 hoc nature of the Bluetooth scatternet, routing of 

packet data between a sending station and a receiving 
station, of which any of the Bluetooth devices of the 
scatternet can be formed, conventional routing of 
packet-formatted data are not readily adaptable for 

30 use in an ad hoc network. The routing protocol, and 
associated data structures utilized pursuant to an 
embodiment of the present invention overcome the 
limitations of the existing art by which packet data 
is conventionally communicated. More particularly, in 
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an embodiment of the present invention, each of the 
Bluetooth devices of the scatternet 10 are provided 
with additional data structures which store data 
utilized to route a packet of data from device-to- 
5 device between a sending device and a receiving 

device. The Bluetooth devices shall herein also be 
referred to as nodes in which a sending device forms a 
data source node and a receiving device forms a data 
destination node. One or more other devices might be 

10 positioned between the data source and data 

destination nodes and such devices shall herein, at 
times, be referred to as intermediary nodes. 

Pursuant to an embodiment of the present 
invention, each Bluetooth device includes a storage 

15 element 24 at which tables 26, 28, and 32 are defined. 
Figure 2 illustrates the storage element 24 and the 
tables 26-32 of the master device 16 and the slave 
device 18-1. Each of the other devices of the 
scatternet also include the storage element 24 and 

20 have the tables 26-32 defined therein. 

Also pursuant to an embodiment of the present 
invention, a new packet header structure is defined. 
The packet header structure is formatted to form the 
header portion of each packet of data communicated 

25 between a data source node and a data destination 

node. Figure 3 illustrates the format of the header 
structure of an exemplary header, shown at 36, 
provided pursuant to an embodiment of the present 
invention. The header 3 6 shall also herein, at times, 

30 be referred to as a piconet header. The header 3 6 is 
used in substitution of a conventional, IP header of 
conventional, IP- formatted data. 

The packet header 3 6 is here shown to include six 
fields, here fields 38, 42, 44, 46, 48, and 52, and an 
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address 54. The fields 38-52 together are of four 
octets (thirty-two bits) , and the address 54 is 
selectably of thirty-two bits or one hundred twenty- 
eight bits, depending upon whether a transport 
5 layer/user assumes IPv4 or IPv6 operation. 

The field 38 is a version field which provides 
coexistence with an IPv4 or IPv6 stack. Different 
ones of the nodes of the scatternet may have different 
interfaces, and the IPv4 and IPv6 may be the default 

10 networking protocols thereat. The header 36 can be 
based upon IPv4 and IPv6 and such alternate 
derivatives of IPv4 and IPv6 are indicated by 
different versions at the version field 38. 

The field 42 forms a local ID field, here a 

15 three-bit AM_ADDR address currently assigned to the 
sending node, either the data source node or an 
intermediary, i.e., forwarding, node in a piconet. If 
the sender is the master device of the piconet, in the 
exemplary implementation, the zero-identifier is 

20 utilized, *000' . 

The field 44 forms a single-bit broadcast flag. 
If the broadcast flag is set, the packet to which the 
header is associated forms a broadcast packet to be 
broadcast by every forwarding master. 

25 The field 46 forms a next-header field which 

corresponds to the next-header field specified in 
IPv6. When the header 36 replaces an IPv4 header, 
instead, the next-header field 46 takes on the 
functionality of the protocol field of IPv4. 

30 The field 48 forms a single-bit reply flag. When 

a packet of data is communicated from a data source 
node to a data destination node, the flag is set to be 
of a zero value, and when the packet is communicated 
from a destination node back to the source node, e.g., 
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a reply to the original packet, the reply flag is set 
to a one value. As shall be noted below, the value of 
the reply flag indicates to which side of the table 26 
should be checked during operation of communication of 
5 a packet of data pursuant to an embodiment of the 
present invention . 

The field forms a sequence number field. The 
sequence number field identifies each packet uniquely 
in a piconet, together with the local ID field 42. 

10 The address 54 is of values to identify the IP 

destination address of a first packet between two end 
points. The length of the address field 54 is 
dependent upon which of the IPv4 or IPv6 protocols is 
assumed by the transport layer. 

15 Comparison of the header 36 with a conventional 

IP header (not shown) indicates that a link field, 
conventionally contained in a conventional IP header, 
does not form a portion of the header 36. Information 
about the link field is taken from an underlying 

20 layer, e.g., a L2CAP layer. 

Figure 4 illustrates the table 2 6 which forms a 
portion of the storage element 24 of each of the 
Bluetooth devices of the Bluetooth scatternet 10 shown 
in Figure 1 and 2. The table 2 6 forms a PicoIP 

25 routing table. The table 26 defines a mapping table 
operable to map incoming packets to outgoing packets. 
Notification that incoming and outgoing is defined for 
the uplink, wherein the direction of the uplink is 
defined by a value of the reply-bit field 48 of the 

30 header 36. If the value of the reply-bit is zero, the 
packet is reverted as going uplink, i.e., from a 
source node to a destination node. And, if the reply- 
bit is of a value of one, the packet is regarding as 
going downlink. The Figure illustrates the table 26 
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to include an incoming ledger 58 and an outgoing 
ledger 62. The incoming ledger 58 includes values of 
the local ID, here indicated at 64 , and a sequence 
number/ here indicated at 66. Values for the elements 
5 64 and 66 are obtained from the fields 42 and 52 t of 
the packet header 36. The outgoing ledger 62 is also 
shown to be formed of a local ID value, here indicated 
at 68, and a new sequence number, here indicated at 
72 . 

10 Figure 5 illustrates the table 28 which also 

forms a portion of the storage element 24 of each of 
the Bluetooth devices forming the scatternet 10 shown 
in Figures 1 and 2. The table 2 8 here forms an IP 
routing table for mapping IP addresses to next-hop 

15 address of a subsequent node in a communication path 

formed between a data source node and data destination 
node. As shown in the Figure, the table 2 8 includes 
an IP address ledger 74 and a next-hop ledger 76. IP 
addresses are stored in the ledger 74 and next -hop 

20 addresses, identified by local IDs, are stored in the 
next -hop ledger 76. The table 2 8 also includes a 
master flag value (M) formed in the column ledger 78. 
The value of the master flag indicates the difference 
between an all-zero broadcast address and the local ID 

25 to indicate a master. 

Figure 6 illustrates the table 32 which forms a 
portion of the storage element 24 of each of the 
Bluetooth devices of the scatternet 10 shown in 
Figures 1 and 2. The table 32 maps a currently- 

30 allocated value of AM_ ADDRs to the same devices' 

BD__ADDRs . When the Bluetooth device forms a slave 
device rather than a master device, the table 32 
contains only the address of the master, the BD_ADDR 
value, or possibly, multiple masters' addresses. As 
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all Bluetooth devices are operable as a master device 
or a slave device depending upon the function of the 
device in a piconet, the tables 26, 28, and 32 are 
common to each of the Bluetooth devices irrespective 
5 of the operation of the respective device as a master 
device or a slave device. 

In operation, when a Bluetooth device is to 
initiate a communication session, the Bluetooth device 
generates and sends a PicoIP header 36 to which a 

10 PicoIP route setup packet is appended to form the body 
of the packet of data. The packet is sent to the 
destination, i.e., the data destination node. When 
the packet is received at the destination node, the 
destination node responds with a packet formed of a 

15 PicoIP header 3 6 without a body portion. The header 
of the reply packet contains values in the fields 
thereof corresponding to the header 36 initially 
generated by the data source node but with a different 
setting of the reply bit in the reply field 48. The 

20 sending of the route setup packet, and the return of 

the reply responsive thereto, causes the tables of all 
intermediary nodes to have data entered therein. 
Subsequent packets of data pursuant to the 
communication session shall contain the same header, 

25 followed by a transport layered data that is to be 

sent by the data source node. A time out is further 
associated with the route setup, and, when expired, a 
new route setup packet is sent out. The procedure is 
repeated for a selected number of times. 

30 Figure 7 again illustrates another representative 

portion of a Bluetooth scatternet 10. Here, again, 
the illustrated portion of the scatternet includes a 
first piconet 12 and a second piconet 14. Here, the 
first piconet 12 is defined by a master device and two 
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slaves. The slaves are designated by 18-1 and 18-2. 
The second piconet is defined by a master 22 and 
includes four slaves. One of the slaves of the master 
22 in the piconet 14 is also the master of the piconet 
5 12, and such Bluetooth devices designated by 16/18-3. 
The other slaves are designated by 18-4, 18-5, and 18- 
6. Operation of an embodiment of the present 
invention shall be described with respect to an 
implementation in which the slave device 18-1 
10 initiates a communication session with the slave 

device 18-6. The communication path is represented by 
the arrow 92 . A packet of data originated at the 
slave device 18-1 passes through two intermediary 
nodes, nodes 16/18-3 and node 22 prior to delivery to 
15 the data destination node, the slave 18-6. As noted 
above, to initiate the session, a PicoIP route setup 
packet is communicated by the device 18-1. The 
information contained in the packet, and the tables 
26, 28, and 32 of the device 18-1 is as follows: 
20 PicoIP routing table 26 {Local ID, 

Sequence Number, Local ID, Sequence 

Number new } ' = { 0 , 0 ; 1 , SNi as t + 1 } 

IP routing table 28 is {IP address, next 

hop, M} = {destination address, 0, l}. 
25 Packet header 36 {Local ID; broadcast 

flag, next header; reply flag} = {l, 0, 

PicoIP Route Setup Packet (xx) 0}. 

The Sequence Number is the sequence number used 
for the last route set up (indicated by SNi a8t ) , 
30 incremented by one. The IP address as contained in 
the packet header is the IP address of the data 
destination node 18-6. This address is retained in 
the header for each hop to the destination. 
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The packet is first provided to the device 16/18- 
3 . Such device records the local ID and sequence 
number, contained in the packet header, and stores the 
extracted information into the PicoIP routing table 26 
5 of the device 16/18-3. The device 16/18-3 then 
transmits two packets, a first of the packets is 
broadcast to all the slaves of the first piconet, in 
which *000' is the destination in the baseband packet. 
And, a second of the packets is forwarded to the node 

10 22, the master of the second piconet. New sequence 
numbers are assigned to every packet in the same way 
as the manner in which a sequence number is assigned 
to the packet at the source node 18-1, that is to say, 
the last used sequence number is incremented by one. 

15 The information contained in the packet header 36 

and in the tables 26-32 of the device 16/18-3 is as 
follows : 

Broadcast packet header {Local ID, 

broadcast flag, next header; reply flag, 
20 Sequence Number} = {0, 0, xx, 0, SN 3 i ave x } 

Packet header for packet to master B 

{Local ID, broadcast flag, next header; 

reply flag, Sequence Number} = {3, 0, xx, 

0, SN slave + 1} . 
25 PicoIP routing table {Local ID, Sequence 

Number, Local ID, Sequence Number new } = {1/ 

SN s iave 1/ 0, SN last +1}; {1/ SN s iave i; 3, SNiast + 

• 2}. 

IP routing table is {IP address, next hop, 
30 M} = {destination address, 0, 0}; {dest. 

address , 0 , 1 } . 

Each slave in the piconet 12 then receives the 
packet, and each slave discards the packet unless the 
slave is the destination node, or participating on 
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another piconet. If the IP routing table thereof 
indicates that the sender of the packet is the next 
hop to the destination, the packet will be discarded. 
For instance, slave device 18-1 discards the packet on 
5 the basis that the node 16/18-3 is the next hop to the 
destination node 18-6. The node 22 also receives the 
packet. As the node 22 is participating only in the 
piconet 14, the node 22 broadcasts the received packet 
to all of its slaves, slaves 18-3, 18-4, 18-5, and 18- 
10 6. 

The information contained in the packet header 36 
in tables 26-32 of the node 22 is as follows: 

Broadcast packet header {Local Id, broadcast 
flag, next header; reply flag, Sequence 
15 Number} = {0, 0, xx, 0, SN s i av e x} ■ 

PicoIP routing table {Local ID, Sequence 
Number; Local ID, Sequence Number new } = {3, 

SN s iave 3/ 0/ SN s iave x} • 

IP routing table is {IP address, next hop, 
20 M} = {destination address, 0, 0}; {dest. 

address , 0 , 0 } . 

Each of the slaves in the piconet 14 discards the 
packet except for the slave 18-6 which forms the data 
destination node. The device 16/18-3 discards the 

25 packet as one of the two entries in its routing table 
28 for the particular address indicates that the next 
hop is the sender of the packet. This overrules all 
other entries. And, the slave 18-6 replies on the 
packet with an empty packet, i.e., the PicoIP header 

30 without an appended body. This packet is returned 

first to the node 22 . The packet header is identical 
to the packet header it received (including the IP 
destination address) , except that the reply flag is 
now set . 
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The information recorded in the packet header 3 6 
and the routing tables 26 and 28 of the slave 18-6 is 
as follows : 

Packet header {Local ID, broadcast flag, 
5 next header; reply flag, Sequence Number} 

= {0, 0, 0, 1, SN mast er b}. 

PicoIP routing table {Local ID, Sequence 

Number; Local ID, Sequence Number new } = {0, 

SN raaster B ; 0 , 0 } . 
10 IP routing table no entry is created here. 

The value of the reply flag 48 causes the 
receiving node, i.e., the node 22, to search the 
incoming ledger side 58 of the routing table 26. This 
produces an indication that the node 16/18-3 is to 
15 form the next hop in the reply back to the initiating 
node, node 18-1. Also, the node 18-6 is set as the 
next hop for the destination address recorded in the 
packet header. The information contained in the 
packet header and the tables 26-32 of the node 22 is 
20 as follows: 

Packet header {Local ID, broadcast flag, 

next header; reply flag, Sequence Number} 

= {3, 0, 0, 1, SN B i av e 3} • 

PicoIP routing table {Local ID, Sequence 
25 Number; Local ID, Sequence Number new } = {3, 

SNgiave 3/ 0/ SN mas ter b} • 

IP routing table {IP address, next hop, M} 
= {destination address, 0, 0}; {dest. 
address, 6 , 0 } . 
30 The node 16/18-3 receives the packet, updates the 

fields thereof according to the PicoIP routing table 
28 of the node 16/18-3 such that the following 
information is contained in the header and tables: 
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Packet header {Local ID, broadcast flag, 
next header; reply flag, Sequence Number} 
= {l, 0, 0 7 1, SN s i aV e i} . 

PicoIP routing table {Local ID, Sequence 
5 Number; Local ID, Sequence Number new } = {1/ 

SN s i a ve 1/' 3, SNgiave 3} • 

IP routing table {IP address, next hop, M} = 
{dest. address, 0, l}. 

The initiating node, node 18-1, looks up the 

10 sequence number with the local ID on the outgoing 

ledger 62 side of the routing table 2 6 thereof, and 
finds all zeros in the incoming ledger thereof. This 
indicates that the packet is destined for the node 18- 
1. All the entries that are entered in the routing 

15 tables are associated with a time out. When the time 
out expires, the entry is removed from the table. In 
this manner, a second entry in the routing table of 
the node 16/18-3, corresponding with the packet 
broadcast to the slaves of the piconet will time out 

20 as no response on this packet shall be received. 

Additionally, each PicoIP header for packets that are 
communicated between the two endpoints, the nodes 18-1 
and 18-6 shall be the same as the headers used for the 
route setup, except for the next-header field. 

25 Thereby, the sequence number is associated with the 
connection for its entire lifetime. Every time in 
which a packet is sent or forwarded by one of the 
nodes in the communication path, the time out 
associated with the routing table entries is 

30 refreshed. 

Additional exemplary operation is illustrated 
with respect to Figure 8. Again, a Bluetooth 
scatternet 10 is again shown, again formed of a first 
piconet 12 and a second piconet 14. The second 
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piconet 14 is connected to a fixed packet data 
network, here the Internet 98. And, destination 
device 102 is connected to the Internet 98. The first 
piconet 12 is shown to be defined by a master and 
5 includes two slaves, slave 18-1 and slave 18-2. The 
second piconet 14 is defined by a master 22 and 
includes three slaves. One of the slaves is also the 
master which defines the first piconet, and is 
referenced by 18-3/16. The other two slaves are 

10 designated by 18-4 and 18-5. Here, for purposes of 
example, a communication session is initiated by the 
node 18-1, to be effectuated with the destination node 
102. The information stored at the tables of the node 
18-1 is as follows: 

15 PicoIP routing table {Local ID, Sequence Number; 

Local ID, Sequence Number new } { = {0, 0; SN s i aV e 3} - 

IP routing table is {IP address, next hop, M} = 
{D, 0, 1}. 

The packet from slave one to master A is composed 

20 as : 

Packet header {Local ID, broadcast flag, 
next header; reply flag, Sequence Number} 

= {l, 0, XX, 0, SN s iave 1 (= SN s lave x) } • 

The tables of the node 16/18-3 are as follows 
25 (the entry related to the broadcast in piconet 12 is 
left out, the broadcast packet will be discarded by 
the receiving nodes, and the entry shall eventually 
time out) : 

PicoIP routing table {Local ID, Sequence 
30 Number; Local ID, Sequence Number new } = {l, 

SN 3 i ave i; 3, SN s iave x}- 

I P rout ing t abl e is {IP address, next hop, M} = 
{D, 0, 1}. 
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The node 18-3/16 sends a packet to the node 22 as 
follows : 

Packet header {Local ID, broadcast flag, 
next header; reply flag, Sequence Number} 
5 = {3, 0, xx, 0, SN s i aV e 3 }. 

The node 16 then broadcasts a packet in the 
piconet 14 and the node also passes the PicoIP packet 
to an agent connected to an access point to the 
Internet 98. The access point is, in fact, built up 
10 from a Bluetooth module, or multiple modules, and the 
agent, and the access point has a connection with the 
Internet. The agent maintains a routing table which 
is shown in Figure 9, and referenced by reference 
numeral 104. For each incoming packet, the table 
15 records the protocol at the column 106 thereof, the 
local ID of the last hop at the column 108, the 
sequence number, as assigned by the last hop, at the 
column 112, the source port number at the column 114, 
and a destination port number at the column 116. Such 
20 values are assigned, by the originator of the packets 

to the related transport layer protocol header fields. 
The ports number fields in the columns 114 and 116 are 
relevant packet indications from the transport layer 
packet, TCP/UDP port numbers, I CMP sequence numbers, 
25 etc. The routing table 104 has the following entries: 
Agent routing table {protocol, Local ID, Sequence 
Number; Source Port Number, Destination Port 
Number; Source Port Number neW / Destination Port 
Number ne w} = {4/6, 3, SN s i aV e 3; SourcePort s i ave 3/ 
30 DestPort s 

lave 3/ SourcePor t new , Des t Port s iave 3}. 4/6 
refers to IPv4 or .IPv6. 

The agent replaces the PicoIP header 3 6 provided 
thereto with a conventional IP header, version 4 or 6, 
with a destination address being the same as that 
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indicated in the PicoIP packet. The source address is 
a special IP address assigned to the access point, 
e.g., the IP address of the interface that is 
connected to the Internet 98. The agent then replaces 
5 the source port number in the transport layer packet 
with a number that uniquely identifies the connection 
with the mobile node. Every source port number at the 
right hand side of the table 104 is unique on that 
right side for the time period during which it is 

10 recorded in the table 104. The destination port 

number often can be copied from the incoming packet. 
Lastly, the agent routes the IP packets towards the 
destination 102 according to the routing tables. 

When the packet is a PicoIP route setup packet, 

15 the agent determines whether the requested destination 
is available and present in the fixed Internet. If 
so, the agent replies with an empty packet, pursuant 
to normal route setup reply procedures, and adds the 
entry to the PicoIP routing table. If the 

20 determination indicates that the destination is 

unavailable or otherwise not present, the agent does 
not do anything as the destination can be present in 
the scatternet. 

Packets returning from the destination are to be 

25 routed through the Internet backbone and processed 

again by the agent . The agent looks up to determine 
which entry the destination port number recorded in 
the packet matches, the source and destination swapped 
compared to the packet from the agent to the 

30 destination 102. This yields the next hop and 

sequence number in the communication path back to the 
node 18-1. The agent uses this information to compose 
the PicoIP header. Also, the original port numbers 
are restored in the corresponding transport protocol 
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header fields. Then, it send the packet to the next 
hop. The next hop thereafter, the node 18-3/16 
forwards on the packet to the node 18-1. 

Communication paths formed in this manner by way 
5 of an access point to the Internet backbone is 

predicated upon, after initial link establishments, 
that the access point forms a master towards all nodes 
with which the access point communicates. During link 
setups, either the mobile node or the access point can 

10 start up and thus master the connection procedure, but 
when the link is established, the access point 
requests a master- to- slave switch if it is not the 
master. However, the principle of routing protocol is 
also met if the access point were, instead, a slave 

15 node. Operation of an embodiment of the present 

invention takes into account the mobility limited of 
Bluetooth devices which forms nodes. That is to say, 
many Bluetooth devices forming terminals shall be 
mobile, and movement of such nodes affects the routing 

20 tables of such nodes. In a node moves, the node 
either changes its location within the Bluetooth 
scatternet, or the node disappears, i.e., moves out of 
communication range with the scatternet. Such 
movement makes all routes the moving node had 

25 previously been involved with invalid. If this occurs 
during an exchange of packets between two nodes, both 
nodes shall lose the packets. Also, link quality can 
be a grade below a minimum threshold for a time, such 
as due to sudden temporary interference. To the other 

30 nodes this also appears to be temporary movement, or 
disappearance, of the a node. A third type of link 
change occurs when a node enters power- save mode, and 
therefore releases its local identifier AM_ADDR. All 
of this is implied by using wireless communication 
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devices and must be accounted for in a routing 
protocol. The routing protocol of an embodiment of 
the present invention features two mechanisms for 
handling such nodal movements. 
5 A first mechanism for handling node mobility is 

the device-to-member address mapping table 32 forming 
a portion of each node and as shown in Figure 6. The 
table 32 is maintained by every node but differs 
depending upon whether the node is a master or a 

10 slave. The table indicates the validity of routes to 
a certain node, indicated by its local ID, or a member 
address, AM_ADDR, in the other tables. Master devices 
keep track of the member addresses that are currently 
assigned to the master device as slaves thereto. If a 

15 slave device disconnects or disappears, the AM__ADDR 
associated therewith is released. The value of 
AM_ADDR is without significance in the absence of 
keeping track of the actual nodes to which the address 
is assigned. Therefore, if an AM_ADDR is released, 

20 this can occur either explicitly when a node goes into 
a sleep mode or implicitly when a node does not return 
or acknowledge a number of packets of data. The 
corresponding entity is removed from the mapping 
table. Also, entries containing the value of the 

25 local ID, i.e., AM_ADDR, are removed from the PicoIP 
and the IP routing tables *26 and 28, respectively. 
And, if the access point is involved, the value is 
also removed from the agent routing table ■ 104 . All 
such entries identify a particular node, namely, the 

30 node to which the master assigns to the particular 

value of AM_ADDR. If a node enters a sleep mode, the 
master is able to keep track of the packet destined to 
it and it may activate the node again when packets are 
waiting for the node. 
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An originator of a packet to a certain 
destination determines whether a route has become 
invalid by use of time outs. Intermediate nodes 
should inform the packet originator of the route 
5 failure by returning a route error package. Such a 
route error packet is composed of a PicoIP packet 
header similarly to a packet returning from the 
destination, followed by an ICMP packet of type host 
unreachable, serving as route error packet. This 

10 route error packet is processed by every intermediate 
node which then erases the relevant entries from their 
respective routing tables. This is a second mechanism 
by which to handle mobility of the Bluetooth nodes. 
Nodes that disappear from the piconet shall trigger a 

15 repeated search by nodes that were communicating with 
such nodes at the time of route failure. 

Thereby, a manner is provided by which to route 
packets of data between a data source node and a data 
destination node in a tooth scatternet . Routing 

20 tables are provided to each tooth device. A new 

packet header structure is provided, and values are 
extracted therefrom to be stored in the new routing 
tables. Such routing tables identify the manner by 
which to forward a packet of data provided thereto in 

25 a hop-by-hop manner to effectuate communication of a 
packet of data from a data source node to a data 
destination node. 

The previous descriptions are of preferred 
examples for implementing the invention, and the scope 

30 of the invention should not necessarily be limited by 
this description. The scope of the present invention 
is defined by the following claims: 
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We claim: 

1. In a multinode , ad hoc, wireless 
communication system having at least a data source 
node and a data destination node, an improvement of 
5 apparatus for facilitating routing of packets of data 
between the data source node and the data destination 
node by way of a communication path, the communication 
path having at least one node, inclusive of the data 
destination node, said apparatus comprising: 
10 at least one first routing table having 

an incoming data ledger and an outgoing data ledger, 
said first routing table for mapping an incoming data 
packet to an outgoing data packet. 



15 communication path includes a first node and at least 
a second node, and wherein said at least one first 
routing table comprises a first routing table located 
at the first node and a first routing table located at 
the second node. 

20 3 . The apparatus of claim 2 wherein the first 

node comprises the data source node and the at least 
the second node comprises an intermediary node, 
positioned along the communication path between the 
data source node and the data destination node, 

25 wherein the incoming data ledger of the first routing 
table located at the data source node includes an 
indication of an identifier identifying the data 
source node, and an indication of an identifier 
identifying the packet of data to be communicated by 

30 the data source node. 



2 . 



The apparatus of claim 1 wherein the 
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4. The apparatus of claim 3 wherein the 
outgoing data ledger of the first routing table 
located at the data source node includes an indication 
of an identifier identifying the data source node and 

5 an indication of the identifier identifying the packet 
of data to be communicated by the data source node, 
incremented by an incrementation value. 

5. The apparatus of claim 4 wherein the first 
routing table located at the intermediary node 

10 includes an incoming data ledger and an outgoing data 
ledger, the incoming data ledger thereof including an 
indication of an identifier identifying the data 
source node and an indication of an identifier 
identifying the packet of data communicated by the 

15 data source node to the intermediary node, and the 

outgoing data ledger thereof including an indication 
of an identifier identifying the intermediary node in 
the communication path and an indication of an 
identifier identifying the packet of data to be 

20 communicated by the intermediary node to a subsequent . 

6. The apparatus of claim 5 wherein the 
subsequent node comprises the data destination node, 
the data destination node further having a first 
routing table, said first routing table further having 

25 an incoming data ledger and an outgoing data ledger, 

the incoming data ledger including an indication of an 
identifier identifying the intermediary node and an 
identifier identifying the packet data incremented by 
the incrementation value and the outgoing data ledger 

30 thereof including an indication of an identifier 
identifying the data destination node. 
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7. The apparatus of claim 1 further comprising 
at least one second routing table for mapping an IP 
address to an address of a subsequent node in the 
communication path extending between the data source 

5 node and the data destination node. 

8 . The apparatus of claim 7 wherein the 
communication path includes a first node and at least 
a second node, and wherein said at least one second 
routing table comprises a second routing table located 

10 at the first node and a second routing table located 
at the second node. 

9 . The apparatus of claim 7 wherein the 
multinode, ad hoc, communication system comprises a 
Bluetooth scatternet, wherein the data source node and 

15 the data destination node each comprise mobile 

Bluetooth terminals, the Bluetooth scatternet defining 
at least one node in the communication path to be a 
master node and at least one node in the communication 
path to be a slave node, said apparatus further 

20 comprising at least one third mapping table, said 

third mapping table having a local identifier ledger 
and a globally-unique identifier ledger, said third 
mapping table for mapping a currently-allocated local 
identifier to a globally-unique identifier. 

25 10 . The apparatus of claim 1 further comprising 

a packet header generator coupled to receive data to 
be communicated by the data source node, said packet 
header generator for generating a packet header to be 
combined with a portion of the data to be communicated 

30 to by the data source node to form packet data, the 
packet header generated by said packet header 
generator including a local identification field 
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indicating a local address by which the data source 
node is identified, a broadcast flag field identifying 
whether the packet data forms a broadcast packet, a 
next-header field indicating a next-header value, a 
5 sequence number field indicating a packet identifier, 
and a destination address field indicating an address 
of a node in the communication path. 

11. The apparatus of claim 10 wherein 
information contained in the packet header is 

10 extracted to be stored at the incoming data ledger and 
the outgoing data ledger of said at least one routing 
table . 

12. In a multinode, ad hoc, wireless 
communication system having at least a data source 

15 node and a data destination node between which data 
packets are communicated, an improvement of a data 
formatter for formatting data to be communicated into 
•the data packets, said formatter comprising: 

a local identification field generator 
20 for generating a local identification field into which 
values indicative of a local address by which the data 
source node is identified are inserted; 

a next -header field generator for 
generating a next-header field into which next-header 
25 values are inserted; 

a sequence number field generator for 
generating a sequence number field into which values 
which identify the packet data are inserted; and 

an address field generator for 
30 generating an address field into which values which 
identify the data destination node are inserted. 
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13 . The formatter of claim 12 wherein the 
multinode, ad hoc, wireless communication system 
comprises a Bluetooth scatternet, wherein the data 
source node and the data destination node each 
5 comprise mobile Bluetooth terminals, wherein the 

Bluetooth scatternet includes at least one piconet, 
and wherein the local address inserted into the local 
identification field comprises a terminal identifier 
within the at least one piconet. 

10 14 . The formatter of claim 12 wherein the values 

inserted into the sequence number field which identify 
the packet data identifies the packet data within the 
piconet . 

15. A method for facilitating routing of packets 

15 of data upon a multinodal communication path including 
at least a data source node and a data destination 
node in an ad hoc, wireless communication system, said 
method comprising: 

forming at least a first routing table 

20 at each node of the communication path, the first 

routing table having an incoming data ledger and an 
outgoing data ledger; 

routing the packet data upon the 
communication path; and 

25 as the packet data .is routed to each 

node of the communication path, extracting first 
.selected information from the packet data and 
inserting the information into the incoming data 
ledger and of the first routing table, selectably 

30 amending the packet data, and inserting second 

selected information into the outgoing data ledger of 
the first routing table. 
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16. The method of claim 15 wherein the first 
selected information inserted into the incoming data 
ledger at each node includes an indication of an 
identifier of a prior node through which the packet 

5 data is routed and an indication of an identifier 

identifying the packet data to be communicated through 
the communication path. 

17. The method of claim 16 wherein the second 
selected information inserted into the outgoing ledger 

10 at each node includes an identifier identifying the 
node at which each respective first routing table is 
located . 

18. The method of claim 15 further comprising 
the additional operation of forming a second routing 

15 table at each node of the communication path, each 

second routing table for mapping an IP address to an 
address of a subsequent node in the communication 
path. 

19. The method of claim 18 wherein the ad hoc, 
20 wireless communication system comprises a Bluetooth 

scatternet, wherein the data source node and the data ■ 
destination node each comprise Bluetooth terminals, 
said method comprising the further operation of 
forming a third mapping table at each node, the third 
25 mapping table having a local identifier ledger and a 
identifier ledger, each third mapping table for 
mapping a currently-allocated local identifier to an 
identifier . 

20. The method of claim 19 further comprising 
30 the operation of generating a packet header for each 

data packet of the packet data. 
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